Machine-to-Machine (M2M) communications involve the communication (using wired or wireless means, or a combination of both) between two machines without human intervention. It is noted here that the term “M2M communication” is also referred to as “Machine Type Communication (MTC)” in certain literature. Hence, these terms may be used interchangeably in the discussion herein. Some examples of M2M communications are: smart metering (e.g., remote reading of a utility meter), healthcare monitoring (e.g., remote monitoring of a patient's heart rate), agricultural monitoring (e.g., monitoring of a crop condition), forest supervision (e.g., monitoring of illegal poaching or logging), fleet management tracking (e.g., monitoring current status of trucks on the road), security surveillance (e.g., automatic, real-time monitoring of a building or complex), billing transactions, inventory management (e.g., through monitoring of Point of Sale (POS) transactions in a supermarket), and the like. Many M2M devices are detection instruments with deployment over large geographical areas and relatively low access to power. The M2M communications typically use MTC-capable sensors or diagnostic devices (which may perform the metering, monitoring, etc., mentioned earlier) on one end and an M2M user device, receiver or server on the other end to receive data (e.g., wirelessly via a cellular Access Network (AN) as discussed below with reference to FIG. 1) from the sensor devices and process the data as per desired M2M service (e.g., utility metering service, healthcare monitoring service, billing preparation service, and the like).
M2M communications are expected to contribute heavily to connectivity and traffic within the mobile broadband industry. The GSM/EDGE system (where “GSM” refers to Global System for Mobile communications and “EDGE” refers to Enhanced Data Rate for GSM Evolution systems) already serves a rapidly expanding market for MTC. Mobile communications operators have expressed interest in accommodating traffic serving wireless sensors/devices within modern evolved networks, such as those based on Third Generation Partnership Project's (3GPP) Long Term Evolution (LTE). GSM/GPRS (where “GPRS” refers to General Packet Radio Service) are getting older and operators aim at totally replacing them with more modern networks. As part of this, it would also be incumbent on the operators to handle MTC traffic served by existing cellular networks (such as GSM/EDGE networks), and to also provide a transition for such traffic from, e.g., GPRS/EDGE to future versions of cellular systems such as International Mobile Telecommunications-Advanced (IMT-Advanced) systems (e.g., 3GPP LTE Advanced or LTE-A systems).
Wireless sensor networks have gained increasing interest from academia and industry. However, such networks have been predominantly built around short range communication links, such as those based on Bluetooth®, and, more recently, on the Zigbee® standard. Hence, it is of interest to examine whether existing and future cellular systems can be modified to efficiently accommodate the traffic from these wireless devices. This is a challenging task considering that: (1) The latest versions of existing cellular systems—e.g., 3GPP systems such as Wideband Code Division Multiple Access (WCDMA) based High Speed Packet Access (HSPA) systems, LTE or LTE-A systems, or systems based on Institute of Electrical and Electronics Engineers (IEEE) standards such as, for example, Worldwide Interoperability for Microwave Access (WiMAX) systems based on IEEE 802.16e and 802.16m, etc.—are conceived with the primary goal to provide service mainly to Mobile Broadband (MBB) users. (2) There is a requirement from operators that these wireless devices (such as sensors or M2M devices) have low cost and high energy efficiency.
Prior to proceeding further, it is noted here that, in the discussion below, the terms “wireless device”, “MTC device,” “M2M device,” “M2M entity,” “M2M communication entity,” or other such terms of similar import may be used interchangeably for ease of discussion. It is understood that an “M2M device” is a device, sensor, or instrument that is capable of M2M communication in a wireless manner. Depending on a given context, the term “wireless device” may refer to an M2M Device (whether Direct Access or Indirect Access (discussed below)) or an M2M Gateway (GW) or both. However, if context dictates otherwise, a device and a gateway may be specified individually rather than through the common terms “MTC device” or “M2M Device.” In certain embodiments, a “wireless device” may include a non-M2M device as well. Furthermore, it is noted here that an M2M communication entity or device may represent a User Equipment (UE) or a Mobile Station (MS) (also known by various analogous terms such as “mobile handset,” “wireless handset,” “wireless device,” “terminal,” etc.) properly configured for M2M communications. Some examples of such mobile handsets/devices include cellular telephones or data transfer equipments (e.g., a Personal Digital Assistant (PDA) or a pager), smartphones (e.g., iPhone™, Android™ phones, Blackberry™, etc.), handheld or laptop computers, Bluetooth® devices, electronic readers, portable electronic tablets, etc.
FIG. 1 illustrates an exemplary M2M communications system 10 using fixed and wireless (mobile) Access Networks (AN). The fixed access networks are identified by reference numerals “12” and “14”, whereas the wireless mobile AN is identified by reference numeral “16.” The wireless mobile AN 16 may be a 3GPP cellular AN or an International Mobile Telecommunication (IMT) Radio Access Network (RAN) such as, for example, a Universal Terrestrial Radio Access Network (UTRAN), an Evolved-UTRAN (E-UTRAN), a GSM/EDGE RAN (GERAN), a WiMAX network, and the like. Various M2M devices are identified using reference numerals “18” through “30.” As shown by broken bi-directional arrows 32-34 (in dash-dot format “- • - • -”), all of these access networks 12, 14, 16 eventually connect their respective M2M devices 18-30 to an Internet-based service network 36 that may host an M2M server 38 from an M2M Service Provider (SP). The server 38 may remotely control or “operate” the M2M devices 18-30 as well as receive and process data sent by these devices. For example, if an M2M communication entity is a building surveillance sensor or unit, the M2M server 38 in that case may be a remote data collection/processing unit that may instruct the surveillance sensor to transmit surveillance data thereto at predefined time intervals (so as, for example, not to overload cellular network resources). It may be possible that the M2M service provider is also the operator or provider of the cellular and/or fixed access networks. On the other hand, the M2M SP may be independent of the cellular or fixed AN operator, but may have a business relationship with these network operators for interoperability purposes. Similarly, the fixed networks 12, 14 and the mobile network 16 may be owned and/or operated by different service providers/operators or the same service provider/operator.
The fixed access networks 12, 14 may be broadband networks that provide Internet Protocol (IP) connectivity to their respective wireless devices 18-21 and 28-30 using a non-cellular access, which is indicated by dashed (“- - - -”) bi-directional arrows 41-43 and 45-47. On the other hand, because of advances in fixed-mobile convergence, a fixed access network may provide IP connectivity via a cellular access as well. In FIG. 1, all 3GPP cellular accesses are shown by dotted (“.....”) bi-directional arrows 50-54. Thus, in case of fixed AN 14, the wireless device 27 may communicate with and through the network 14 via a 3GPP Home Evolved Node-B (HeNB) or Home Node B (HNB) 56 as indicated by the arrow 54 depicting such 3GPP cellular access.
Referring again to fixed networks 12, 14, it is observed here that some of the M2M communication entities 19-21 and 28-30 may be interconnected with one another, with other similar entities (not shown), or with one or more M2M Gateways (e.g., the M2M Gateways (GW) 21 and 30) via “local” M2M area networks 60, 62, which could be IEEE 802.15.1, Bluetooth®, or other similar Wireless Local Area Networks (WLAN) (e.g., a WiFi network). It is noted here that a wireless device may be a Direct Access M2M device (e.g., devices 22-23 and 27) that supports direct access to an access network, or an Indirect Access M2M device (e.g., devices 18-20, 24-25, and 28-29) that does not support direct access to an access network. An M2M gateway (e.g., gateways 21, 26, and 30) may be used to support network access for such Indirect Access M2M devices. The M2M Gateway may function as a concentrator of data received from various such Indirect Access M2M devices communicating therewith. A dedicated Gateway (GW) 64 (which may or may not be and M2M gateway—i.e., which may not be capable of supporting M2M communications) may provide access to an IP network (e.g., the Internet based service network 36) for the M2M device 18 through the fixed network 12.
It is noted here that, in FIG. 1, signaling between a network node and a fixed access network (e.g., between an M2M GW 21 and the fixed AN 12, between the HeNB 56 and the fixed AN 14, etc.) and signaling beyond access networks (whether fixed or wireless) are indicated using unbroken bi-directional arrows 66-72 for ease of illustration and to distinguish initial access-related signaling shown by arrows 40-43, 45-47, 52-54, etc.
The wireless devices 22-23 may directly access 3GPP cellular wireless AN 16 via a base station (e.g., the base station 75) or through the combination of a Relay Node (RN) 76 and the base station 75. On the other hand, the wireless devices 24-25 may indirectly access the network 16 through an M2M GW 26 that communicates with the AN 16 via another base station 78. As in case of wireless devices 19-21 and 28-30, the wireless devices 24-26 also may be interconnected with one another via a “local” M2M area network 80 supporting non-cellular signaling (as indicated by dashed bi-directional arrows 82-84). The wireless AN 16 may further support inter-domain communication between two or more devices (operating under different base stations) without the involvement of the M2M service provider's server 38, as shown by the exemplary bi-directional arrow 86 (also in the dash-dot format “- • - • -”).
In case of cellular access, the term “access network” may include not only a RAN portion (comprising, for example, a base station with or without a base station controller) of a cellular carrier network, but other portions (e.g., cellular backhaul and core network) as well. In FIG. 1, an exemplary IMT Core Network (CN) is shown using reference numeral “88.” As shown in FIG. 1, the cellular AN 16 may include multiple cell sites 89-90, each under the radio coverage of a respective base station (BS) or base transceiver station (BTS) 75, 78. The base stations 75, 78 may be, for example, eNodeBs (or eNBs), high power and macro-cell base stations or relay nodes, etc. These base stations 75, 78 may receive wireless communication (as indicated by exemplary bi-directional arrows 52-53) from various M2M communication entities 22-26, and forward the received communication to the Core Network 88. In case of a Third Generation (3G) RAN, for example, the cellular backhaul (not shown) may include functionalities of a 3G Radio Network Controller (RNC) or Base Station Controller (BSC). As mentioned earlier, portions of the backhaul (such as, for example, BSC's or RNC's) together with base stations 75, 78 may be considered to comprise the RAN portion of the network. The Core Network (CN) 88, on the other hand, may provide logical, service, and control functions (e.g., subscriber account management, billing, subscriber mobility management, etc.), Internet Protocol (IP) connectivity and interconnection to other networks (e.g., the Internet or the Internet-based service network 36) or entities, roaming support, etc. The CN 88 may be, for example, an IMT CN such as a 3GPP CN or a 3GPP2 CN (for Code Division Multiple Access (CDMA) based cellular systems), or an ETSI TISPAN (European Telecommunications Standards Institute TIPHON (Telecommunications and Internet Protocol Harmonization over Networks) and SPAN (Services and Protocols for Advanced Networks)) CN.
From the above discussion, it is seen that the system 10 in FIG. 1 allows M2M communications among two or more M2M devices/sensors 18-30 via respective networks (fixed or wireless), and also between one or more of these devices and their respective networks. Because the present disclosure is related to radio resource management in a wireless network (primarily a mobile communication system), the discussion below will not further discuss signaling or resource conservation aspects in the context of a fixed network.
Signaling mechanisms in existing and future 3GPP and IEEE wireless networks have been conceived with the intention of securing a robust connection or session lasting for long periods of time and involving transmission of large volumes of data. In this respect, signaling mechanisms and protocols involving several long messages amounting to hundreds or thousands of kilobytes of data are not considered as particularly significantly overhead, especially when compared with the large amount of data traffic (in mega- and giga-bytes of data) exchanged within a session. In other words, current and future cellular and IEEE networks treat protocol-related signaling (including UL and DL radio resource scheduling related signaling discussed below) as a relatively “minor” traffic when compared to the significantly larger payload data.
On the other hand, in the most common scenario, the M2M devices 22-27 shown in FIG. 1 are anticipated to transmit—in each uplink transmission—only a single packet containing measurements or warnings, or any other type of information to the cellular network (or respective base station). In case of wireless devices used in M2M communication, data transmissions occur mainly in the uplink (i.e., from the device to the network), whereas the downlink (from the network to the device) serves mainly for transmitting feedback and link control information to devices. Thus, terminals operating in a wireless network may exchange information (which includes data, scheduling and control information, feedback information, etc.) via a base station in the network over a communication channel or link (e.g., a Radio Frequency (RF) channel) (conveniently referred to herein as the “channel”) between the base station and the wireless terminals.
Channel-Dependent Scheduling
A “scheduler” is used in a wireless network (e.g., as part of a base station in a cellular network such as a 3GPP LTE network) to determine to/from which terminal(s) to transmit/receive data and on which set of radio resource(s) in the different domains (time, frequency, etc.) of the communication system. A scheduler is a key element of the network and, to a large extent, determines the overall behavior of the system.
In a situation where the channel quality varies significantly with the frequency while the channel quality only varies slowly with time, channel dependent scheduling in the frequency domain can enhance system capacity. This is typically the case in wideband indoor systems with low mobility, a scenario which is very likely to be the case in some M2M deployments.
To select a suitable data rate (in practice, a suitable modulation scheme and channel coding rate), as well as suitable power (transmitted or received) for the channel-dependent scheduling, the transmitter needs information about the radio-link channel conditions.
FIG. 2 illustrates general principles of channel-dependent scheduling in the downlink. Steps 1 through 3 in FIG. 2 depict how Downlink (DL) channel status is reported. For the downlink, most systems provide a downlink signal of a predetermined structure, known as the downlink pilot or the DL Reference Signal (RS). This reference signal is transmitted (step 1 in FIG. 2) from a base station (e.g., the base station 92 in FIG. 2) with a constant power and can be used by a mobile terminal (e.g., the terminal 94 in FIG. 2) to estimate the instantaneous downlink conditions (step 2 in FIG. 2), which can then be reported to the base station (step 3 in FIG. 2). The mobile terminal 94 can be an M2M device or a UE or other mobile handset that is capable of M2M communication. What is relevant for the transmitter (i.e., the base station 92) is an estimate reflecting the channel conditions at the time of the transmission. Thus, the more rapid the time-domain channel variations are, the less efficient link adaptation is. Because there inevitably will be a delay between the point in time when the terminal measures the channel conditions and the application of the reported value in the transmitter, channel-dependent scheduling and link adaptation typically operates at its best at low terminal mobility.
FIG. 3 illustrates general principles of channel-dependent scheduling in the uplink. Steps 1 through 3 in FIG. 3 depict how Uplink (UL) channel status is determined. For the uplink, estimation of the uplink channel conditions is not as straightforward, as it will be described later in the case of LTE systems. In order for an uplink scheduler in an eNodeB to determine uplink channel quality, the UE 94 must send Sounding Reference Signals (SRS) as input to the base station or eNodeB 92 (step 1 in FIG. 3). The base station 92 (and, more specifically, the scheduler in the base station) may estimate UL channel quality from the SRS signal (step 2 in FIG. 3) and then allocate appropriate radio resources to the UE 94 via an UL scheduled grant based on the estimated UL channel quality (step 3 in FIG. 3). It is worth mentioning that a Time Division Duplex (TDD) system (such as an LTE system) could rely on channel reciprocity, however this may not provide a full knowledge of UL channel conditions.
Although the scheduling strategy is implementation-specific and not specified by 3GPP, the overall goal of most schedulers is to take advantage of the channel variations between the mobile terminals, and preferably schedule transmissions to a mobile terminal on resources with advantageous channel conditions. This is valid for both LTE and HSPA. The main advantage in the LTE case is the fact that one can also exploit the frequency diversity, whereas, in HSPA, the scheduler can only exploit time-domain variations. For large bandwidths supported by LTE, where a significant amount of frequency-selective fading often will be experienced, the possibility for the scheduler to exploit the frequency domain becomes extremely important compared to exploiting only the time-domain, especially at low speeds or for fixed devices (such as M2M devices/gateways) where the variations in the time domain are relatively slow compared to the delay requirements set by many services.
In summary, most channel-dependent scheduling strategies, either in the uplink or in the downlink, need some information about: (i) Channel conditions at the terminal/base station; (ii) buffer status (at the terminal/base station) and priorities of the different data flows; and (iii) interference situation in neighboring cells. There are different ways this information could be obtained at the scheduler, but, generally, a scheduler relies on some sort of reported information from the terminals to the network.
Because the inventive aspects of the present disclosure are discussed later with reference to an LTE system, the discussion below now provides general background information about scheduling in LTE. Similar scheduling approaches may be present in other non-LTE systems as well, but, for the sake of brevity, only the LTE system is discussed below. However, such LTE-limited discussion should not be construed to limit the scope of the present disclosure to LTE-based systems only. Rather, as mentioned later, the teachings of the present disclosure can be applied to other non-LTE systems as well.
Scheduling in LTE
In LTE, the scheduler is part of the Medium Access Control (MAC) layer and controls the assignment of uplink and downlink radio resources. The eNodeB makes a scheduling decision for each 1 ms of Transmission Time Interval (TTI) (i.e., 1 ms subframe of a 10 ms radio frame in LTE) and sends scheduling information to the selected set of terminals. There is also a possibility for semi-persistent scheduling to reduce the control-signaling overhead.
Uplink and downlink scheduling are separated in LTE, and uplink and downlink scheduling decisions can be taken independently of each other. In LTE, the basic scheduling operation is so-called dynamic scheduling, where the eNodeB sends scheduling information in each 1 ms TTI (or subframe) to the selected set of terminals (over Physical Downlink Control Channels (PDCCHs)), controlling the uplink and downlink transmission activity. The terminal follows scheduling commands, for both uplink and downlink, from a single cell only—i.e., the serving cell.
LTE Downlink Scheduler
FIG. 4 shows an exemplary operational arrangement for an LTE downlink scheduler 96. The DL scheduler 96 may be part of a base station or eNodeB 92. For ease of discussion, the same reference numeral “92” is used in FIGS. 2-5 to refer to a base station or eNB, and the same reference numeral “94” is used in FIGS. 2-5 to refer to a UE (which, as mentioned before, may be an M2M communication entity as well) or a dedicated M2M device or other wireless terminal. In LTE, the downlink scheduler 96 is responsible for dynamically controlling the terminals to transmit to and, for each of these terminals, the set of Resource Blocks (RBs) upon which the terminal's Downlink Shared Channel (DL-SCH) should be transmitted. Transport format selection (i.e., the selection of transport block size, modulation scheme, and code rate) and logical channel multiplexing for downlink transmissions are typically controlled by the eNodeB 92.
In most cases, a single terminal cannot use the full capacity of the cell, for example, due to lack of data. Also, as the channel properties may vary in the frequency domain, it is useful to be able to transmit to different terminals on different parts of the spectrum. Therefore, the scheduler 96 may schedule multiple terminals in parallel in an LTE subframe, in which case there is one DL-SCH per scheduled terminal, each such terminal is dynamically mapped to a (unique) set of frequency resources. The scheduler 96 is in control of the instantaneous data rate used, and, hence, the Radio Link Control (RLC) segmentation and MAC multiplexing will be affected by the scheduling decision. Although formally part of the MAC layer, the scheduler 96 controls most of the functions in the eNodeB 92 associated with downlink data transmission such as, for example, (i) RLC segmentation/concatenations of different RLC data buffers 98-1 through 98-n in the eNB 92 for different scheduled terminals; (ii) MAC multiplexing of logical channels (which may be carried out using a MAC multiplexing unit 100), and (iii) L1 coding, modulation and number of transmission layers in the case of spatial multiplexing (all of which may use a modulation and coding unit 102 in the eNodeB 92). The choices of these parameters are mainly determined by the data rate, that is, the transport block size.
Information about channel conditions at the terminal can be obtained in several ways. Typically, the eNodeB 92 relies on what is called a “channel-status” report (described later below) from the terminal 94, as indicated by dashed arrow 104 in FIG. 5 (and by step 3 in FIG. 2). (The UE 94 may estimate DL channel quality to be reported to eNodeB 92 as discussed earlier with reference to step 2 in FIG. 2.) However, additional sources of channel knowledge can also be exploited by a particular scheduler.
In addition to the channel quality, the scheduler 96 may also take terminal's buffer status and priority levels into account. It does not make sense to schedule a terminal with empty transmission buffers. On the other hand, priorities of the different types of traffic may also vary. For example, Radio Resource Control (RRC) signaling may be prioritized over user data, and RLC and Hybrid Automatic Repeat Request (HARQ) retransmissions may take priority over initial data transmissions.
LTE Downlink Scheduler: Channel-Status Reporting
As mentioned earlier, terminals operating in a wireless network may exchange information via a base station in the network. The exchange may be in the form of channel feedback or channel status report for the communication channel/link between the base station and the wireless terminals. Although referred to as “channel status reports”, what a terminal delivers to the network in LTE are not explicit reports of the downlink channel status. Rather, what the terminal delivers are recommendations on what transmission configuration and related parameters the network should use if/when transmitting to the terminal on the Downlink Shared Channel (DL-SCH).
The channel status reports may include, for example, one or more of the following: (i) A Rank Indicator (RI) to indicate channel rank or the number of useful transmission layers (for the data channel) that may be preferably used by/for downlink transmission to the terminal. (ii) A Precoder Matrix Indicator (PMI) indicating a preferred precoding matrix for shaping the transmit signal (to be sent to the UE). The reported precoder may be determined assuming the number of layers indicated by the RI. PMI is typically only reported if the terminal is configured to be in closed-loop spatial multiplexing mode. In case of open-loop spatial multiplexing, the network instead selects the precoder matrix to use for transmission according to a pre-defined rule (rather than receiving the precoder recommendation from the terminal). The precoder recommendation may be frequency-selective, implying that the terminal may recommend different precoders for different parts of the downlink spectrum. (iii) Channel Quality Indicator (CQI) indicating channel quality of the wireless communication channel between the base station and the UE. The CQI may represent the recommended modulation scheme and coding rate that should, preferably, be used for the downlink transmission. The CQI typically points to a table that consists of a set of pre-defined modulation-scheme/coding-rate combinations.
The channel feedback or channel status report may also include estimates of channel coefficients. The channel feedback may enable the base station to adaptively configure a suitable transmission scheme to improve coverage or user data rate or to more accurately “predict” channel quality for future transmissions to the terminals.
Channel status reports can be categorized as wideband reports, reflecting the status of a channel over the entire cell bandwidths, and per sub-band reports, reflecting status of a channel over each sub-band. The different granularities can be configured by the network obeying a compromise between estimation accuracy and signaling overhead.
The recommendation—i.e., a channel status report—that is delivered by the terminal does not need to be followed by the network. However, information about the actual modulation scheme and coding rate used for DL-SCH transmission is generally always included in the downlink scheduling assignment and the terminal preferably always uses this for demodulation and decoding of the actual DL-SCH transmission.
The channel status reporting can either be periodic or aperiodic (e.g., a trigger-based report). An aperiodic or trigger-based channel status report is delivered when explicitly requested by the network by means of a ‘channel-status request’ flag included in the uplink scheduling grant. This aperiodic channel status report is generally always delivered using Physical Uplink Shared Channel (PUSCH)—i.e., on a dynamically assigned resource. Periodic reports, in contrast, are configured by the network to be delivered with a certain periodicity, possibly as often as once in every 2 ms. The different types of information does not need to be reported with the same period. Typically, RI can be reported less often, compared to the reporting of PMI and CQI, reflecting the fact that the suitable number of layers (as indicated by RI) typically varies on a slower basis as compared to the channel variations (as reported through PMI and CQI) that impact the choice of precoder matrix and modulation rate and coding scheme. Normally, periodic channel status reports are delivered using Physical Uplink Control Channel (PUCCH) physical channel. However, similar to HARQ acknowledgements (which are normally delivered on PUCCH), channel status reports also may be routed to the PUSCH if the terminal has a valid uplink grant and is anyway to transmit on the PUSCH.
LTE Uplink Scheduler
FIG. 5 shows an exemplary operational arrangement for an LTE uplink scheduler 106. As illustrated, the UL scheduler 106 may be part of the base station 92. In certain embodiments, the DL scheduler 96 (FIG. 4) and the UL scheduler 106 (FIG. 5) may be implemented in a single scheduler unit (not shown in FIGS. 4-5, but shown in FIG. 16) having both DL and UL scheduling capabilities. In LTE, the uplink scheduler 106 serves a similar purpose compared to the downlink scheduler 96, namely to dynamically control which mobile terminals are to transmit on their Uplink Shared Channel (UL-SCH) and on which uplink radio resources.
Differently from HSPA, the uplink is orthogonal in LTE and the shared resource controlled by the eNodeB's UL scheduler 106 is time-frequency resource units. The eNodeB scheduler 106 is also responsible for controlling the transport format (i.e., payload (or transport block) size, modulation scheme, etc.) the mobile terminal 94 shall use, which means that there is no need for out-of-band control signaling from the mobile terminal 94 to eNodeB 92. As a consequence, accurate and detailed knowledge about the terminal situation with respect to buffer status and power availability is more accentuated in LTE.
The basis for uplink scheduling are so-called “scheduling grants” (illustrated by step 3 in FIG. 3), containing the scheduling decision (from the UL scheduler 106) and providing the terminal 94 with information about the resources and the associated transport format (e.g., transport block size, and modulation scheme) to use for transmission on UL-SCH. A terminal is allowed to transmit on the UL-SCH only if the terminal has a valid scheduling grant. Dynamic grants may be valid for one subframe (of 1 ms duration). That is, for each subframe in which the terminal is to transmit on the UL-SCH, the UL scheduler transmits a corresponding grant on a downlink PDCCH.
The terminal 94 monitors the set of PDCCHs for uplink scheduling grants. If a valid grant intended for the terminal is detected in a subframe n, the actual transmission of the uplink data takes place in subframe n+4 for Frequency Division Duplex (FDD).
LTE Uplink Scheduler: Frequency-Selective Scheduling
Similarly to the downlink case (discussed earlier with reference to FIGS. 2 and 4), the uplink scheduler 106 can exploit information received from the UE 94 about the channel conditions, buffer status, and priorities of the different data flows, and, if some form of interference coordination is employed (e.g., as discussed later with reference to FIG. 8), the scheduler 106 may also receive information from the UE 94 related to the interference situation in neighboring cells. In FIG. 5, the UE 94 is shown to include a plurality of RLC data buffers 108-1 through 108-m, which are coupled to a UE-based MAC multiplexing unit 110 and a priority handling unit 112. The priority handling unit 112 may report RLC buffer status and associated priorities of different data flows to the UL scheduler 106 as indicated by dashed arrow 114. The MAC multiplexing unit 110 may be coupled to a modulation and coding unit 115, which may receive earlier-mentioned transport format-related control information (e.g., transport block size, and modulation scheme) via the UL scheduling grants sent to the UE 94 from the UL scheduler 106, as indicated by dashed arrow 116 in FIG. 5 (and related to step 3 in FIG. 3).
It is noted here that a detailed discussion of functionalities of units such as RLC buffers, MAC multiplexers, modulation and coding units, etc., is not provided with reference to FIGS. 4 and 5 because of lack of relevance of such discussion to the inventive aspects of present disclosure and because of sufficiently well-known nature of such units.
In the uplink, estimates of the channel quality can be obtained (by the eNodeB 92) from the use of uplink “channel-sounding” using Sounding Reference Signals (SRS) from the UE 94 (as indicated by steps 1 and 2 in FIG. 3). The performance of frequency-selective scheduling (by the UL scheduler 106) using the SRS depends on the sounding bandwidth and the quality of the channel estimate (step 2 in FIG. 3), the latter being a function of the transmission power spectral density used for the SRS. With a large sounding bandwidth, link quality can be evaluated on a larger number of Resource Blocks (RBs). However, this is likely to lead to the SRS being transmitted at a lower power density, due to the limited total UE transmit power, and this reduces the accuracy of the estimate for each RB within the sounding bandwidth. Conversely, sounding a smaller bandwidth can improve channel estimation on the sounded RBs, but results in missing channel information for certain parts of the channel bandwidth, thus risking exclusion of the best quality RBs. As an example, experiments discussed in a Motorola submission “R1-071340: Considerations and Recommendations for UL Sounding RS”, www.3gpp.org, 3GPP TSG RAN WG1 (where “TSG” refers to Technical Specification Group and “WG” refers to Working Group), meeting 48bis, St Julian's, Malta, March 2007, show that at least for a bandwidth of 5 MHz, frequency-selective scheduling based on full-band sounding outperforms narrower bandwidth sounding.
As noted earlier, the uplink scheduler (e.g., the scheduler 106) is in complete control of the transport format the mobile terminal shall use, whereas the logical channel multiplexing is controlled by the terminal according to a set of rules. Thus, uplink scheduling is per mobile terminal and not per radio bearer.